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SECTION 1 
INTRODUCTION 


1.1 Background. The objectives of this element of the NASA Satellite 

Communications Applications Research (SCAR) Program are to develop new advanced on- 
board satellite capabilities that will enable the provision of new services, namely interim 
and full Integrated Services Digital Network (ISDN) services via satellite and to provide a 
system analysis of futuristic satellite communications concepts, namely broadband services 
via satellite. 

This aspect of the NASA SCAR Program provides a research and development effort to: 

1) develop basic technologies and concepts to use the on-board 
processing and switching capabilities of advanced satellites that will 
permit the provision of interim and full ISDN services and 

2) provide a systems and requirements analysis of future satellite 
communications concepts via a new generation of broadband 
switching and processing satellites. 

These objectives will be achieve in part via modeling and simulation of ISDN satellites as 
part of the ISDN terrestrial network. Models of the Interim Service ISDN Satellite (ISIS) 
and the Full Service ISDN Satellite (FSIS) will exercised using discrete event simulation 
techniques. 

To provide meaningful results credible scenarios must be used as simulation inputs and 
realistic performance measures must be correlatable to the advanced ISDN communications 
satellite design parameters. Such scenarios will use the traffic model of ISDN users to 
exercise the network models fully. Performance measures will be evaluated under benign 
and stressed conditions with scenarios that reflect real world diversities. Such scenarios 
must contain information about events that occur both inside and outside the network. 
Examples of network events include network facility failures and surges in service demand. 
High error rates caused by satellite link degradation due to poor weather is an example of 
an extra-network event 



An end-to-end network view must be developed using the framework of the CCITT and 
ANSI standards to establish ISDN performance measures. Network performance 
measures must assess the overall network in terms of speed, capacity, accuracy, access 
reliability, and availability. Component performance measurements must provide insight 
into the engineering performance of the system. The factors of performance measures must 
include propagation delay, signal degradation, message queue lengths, network node 
switching delay and raw throughput. 

1 . 2 Scope. This update report documents the views of the scenario generation 
process and the performance measurement methodology. The process and methodology 
must be applicable to the ISIS and the FSIS systems as described in Figure 1.1, 
"NASA/SCAR Approaches for Advanced ISDN Satellites". The ISIS represents satellite 
systems like the Advanced Communications Technology Satellite (ACTS), orbiting switch. 
ACTS will be controlled by a ground based master control center (MCC), shown in Figure 
1.2, "Closed User-Oriented Scenario". A user of the ACTS satellite switch must request 
services from the MCC, a combination of the NASA Ground Station (NGS) the Master 
Control Station (MCS). The MCC in turn commands the satellite to switch the appropriate 
channel. 

The ultimate aim of this element of the SCAR Program is to move these MCC functions on- 
board the next generation ISDN communications satellite as shown in Figure 1.3, 
"Advanced ISDN Satellite". The technical and operational parameters for the advanced 
communications satellite design will be obtained from an engineering software model of the 
major subsystems of the ISDN communications satellite architecture. Discrete event 
simulation experiments will be performed with the model using various traffic scenarios, 
design parameters, and operational procedures. The data from these simulations will be 
analyzed using the performance measures discussed in this report. 

1 . 3 Document Overview. This update report begins by describing the use 
of modeling and simulation to determine the design parameters for the SCAR advanced 
ISDN communications satellite design. An overview of the modeling and simulation tasks 
includes a brief description of the four software programs of that effort. Particular 
associations are made between the the Scenario Generation Program and the Scenarios 
described in this report , and the Product Generation Program and the Performance 
Measures also identified herein. The two main sections of this update report are Scenario 
Generation and Performance Measures. 
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Figure 1.1 NASA/SCAR Approaches for Advanced ISDN Satellites 
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Figure 1.2 Closed User-Oriented Scenario 
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Figure 1.3 Advanced ISDN Satellite 




The Scenario Generation Section describes the Scenario Generation Program and its 
association with the Traffic Model Database. After a brief description of the database 
elements, they are used in a scenario generation example to demonstrate their flexibility and 
utility in providing Scenario Traffic Files (STFs). Four types Scenario Scripts are defined: 
checkout, baseline, stress, and special scenarios. Each is described in detail together with 
their application to the SCAR advanced ISDN communications satellite design process. 

The Performance Measures Section introduces the concepts, definitions and purposes of 
measurements as tools for evaluating the evolving ISDN communications satellite design. 
Four performance measure categories are identified: throughput, response time, blocking 
probability, and robustness. Each is presented in terms of their major factors, their 
application levels, and their measurement parameters as associated with this NASA SCAR 
effort. A summary matrix is developed associating the performance measures with the 
major communication subsystems, and modeling and simulation modules. 
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SECTION 2 

MODELING AND SIMULATION 


2 . 1 Modeling and Simulation Objective. The objective of this modeling 
and simulation project is to design and develop software models that can be used to 
simulate those aspects of the ISDN communications satellite with sufficient fidelity to assist 
in its design. This end-to-end simulation will include sufficient functionality to 
demonstrate the interactions between each of the four modeling and simulation phases: 
database generation program, scenario generation program, simulation run program, and 
product generation program. A description of each of these programs has been 
abbreviated in order to focus on the the scenario generation and performance measures. 

2.2 Major Modeling and Simulation Tasks. The major modeling and 
simulation tasks for this SCAR Project are depicted in Figure 2.1, "Task Flow Diagram for 
the SCAR Program". Each of these tasks is described in the following sections in order to 
provide an overview of the modeling and simulation process as well as to provide context 
for the scenarios and performance measures: 

2.2.1 Database Generation Program. The Database Generation (DbGen) 
program assembles the major ISDN user characteristics into a machine readable database. 
For this NASA SCAR effort that database consists of the traffic model database of ISDN 
user characteristics. That database is an input to the scenario generation process. A brief 
description of this traffic model database is presented in Section 3.2. 

2.2.2 Scenario Generation Program. The Scenario Generation (ScenGen) 
program selects entries from the user traffic model database and engineering parameter 
databases to generates a list of time ordered, initiating discrete events. The discrete event 
list is call a Scenario Traffic File (STF). The STF is used to initialize the model for a 
specific ISDN communications satellite design and to exercise that satellite design using 
the requests for service dictated by the user traffic. Since this is one of the principal topics 
of this update report Section 3.0 is dedicated to Scenario Generation. 

2.2.3 Simulation Run Program. The Simulation Run (SimRun) program 
consists of a model of the real world communications network of the major ISDN 
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Figure 2.1 Task Flow Diagrams for the NASA SCAR Program 




components. Each of these ISDN communication components is represented by a block 
diagram within the overall architecture of the complete network. 

The SimRun program essentially reads each discrete event from the (STF); takes the 
appropriate action; and logs that action and the corresponding results in a measurement save 
(MSAVE) file. The appropriate action taken by the simulation includes allocating and 
releasing communication resources, denying specific services, and calling other processes 
in-tum. 


2.2.4 Product Generation Program. The Product Generation (ProdGen) 

program reads the data in the MSAVE file and analyses these data in accordance with 
specific algorithms. It is envisioned that there will be as many product generation 
programs as there are issues to be studied: throughput, response time, trace, delay, call 
blocking, busy-minute, busy-hour, etc. The performance measures cited in this report will 
be used a criteria to evaluated the design parameters, operational procedures and degree of 
ISDN communications standard compliance within the products generated by ProdGen. 

2 . 3 Technical Overview. Integrated Services Digital Network (ISDN) is a 

communications architecture that can use existing telephone lines for digital traffic. ISDN 
make use of existing connectivity between users and telephone exchanges. Added services 
are made available by adding new equipment both at the customer end and the telephone 
office end. 

ISDN offers extended user services through the use of digital technology and common 
channel signaling. Access to the digital transport facilities occurs on 64 kbps bearer (B) 
channels while access to the signaling network occurs on 16 kbps (BRI-D) or 64 kbps 
(PRI-D) signaling channels. 

Signal System Number 7 (SS7) provides a separate path for signaling services between 
telephone central offices (COs). In the past trunk lines were used to control the call request 
from one CO to another - known as "in-band" signaling. The "off-hook", ringing signals, 
and switch controls used the same lines as the telephone conversations. These trunks used 
for signaling could not be used for conversations resulting in a loss of revenue. 

A number of signaling architectures have evolved. The surviving architectures have used 
common channel signaling - known as "out-of-band" signaling. Dedicated, less expensive 
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communication paths have been installed between each CO solely for the purpose of 
signaling. It is no longer necessary to use more expensive trunk lines for these services. 

The advanced ISDN communications satellite design under the NASA SCAR Program 
uses as its design starting point the Advanced Communications Technology Satellite 
(ACTS) as a switch in orbit. That ACTS orbiting switch is presently controlled by a 
ground based master control center (MCC), a combination of the NASA Ground Station 
(NGS) and the Master Control Station (MCS). A user of the ACTS satellite switch must 
request services from the MCC. The MCC in turn commands the satellite to switch the 
appropriate channel. 

The ultimate aim of this aspect of this SCAR Program is to move that MCC function on- 
board the satellite for the next generation communications satellite design. The technical 
and operational parameters for the advanced communications satellite design will be 
obtained from an engineering software model of the major subsystems of the 
communications satellite architecture. Discrete event simulation experiments will be 
performed with the model using various traffic scenarios, technical parameters, and 
operational procedures and performance measures. 
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SECTION 3 

SCANARIO GENERATION 


3.1 Scenario Generation Program. The ISDN satellite end-to-end 
simulation is shown in Figure 3.1, "End-to-end Model Architecture". Each program is 
physically and functionally separated by input/output data files. This separation ensures 
that each program is independent and that each project phase is separate from the others. 
The only link between these programs is the data file they share. 

3.2 Traffic Model Database. The Scenario Generation (ScenGen) program 
reads the traffic model database that describes potential ISDN users and the statistical 
information describing the ISDN services requested. See Figure 3.2, "Scenario 
Generation Program". This traffic model consists of a number of databases: the City 
Reference DB, ISDN User vs Industry DB, Application vs Industry DB, Application vs 
Time DB, and Application vs Bearer Services DB. In order to provide a more meaningful 
context for the scenario generation process each of the traffic model database and their data 
elements will be briefly describe: 

3.2.1 City Reference Database (SCAR DB1). This database, Table 3.1, 
"City Reference Database", identifies the percentage of ISDN users that are associated with 
the population of fifty major cities. The geographic coordinates of these of these cities 
together with their US time- zone permit their use with communications satellite network. 
A view of the geographical distribution of these CONUS Cities is shown in Figure 3.3, 
"Traffic Model CONUS City Location. 

3.2.2 ISDN User versus Industry Database (SCAR DB2). This 

database. Table 3.2, "ISDN User vs Industry", apportions the ISDN traffic among twenty- 
one industries. These data permit the scenario selection on an industry-by-industry basis. 

3.2.3 Application versus Industry Database (SCAR DB3). This 
database, Table 3.3, "Application vs Industry Database", further apportions the industry 
into applications of communication services. This added data granularity permits the 
selection of scenarios tailored on an application basis. 
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Figure 3.1 Ehd to End ISDN Model Architecture 
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Table 3.1 City Reference Database 

SCAR Database 1. 

LATITUDE 

ISDNPCT 


CITY NAME 

POPULATION 

LONGITUDE TIMEZONE 


,000 

deg 

deg 

% 

# 

Honolulu 

838 

21 

-157 

•.V* 

3.30 

-5 

Anchorage 

227 

61 

-150 

3.10 

-4 

Seattle-Tacoma 

2,421 

47 

-122 

3.40 

-3 

Portland-Vancouver 

1,414 

45 

-122 

3.10 

-3 

San Francisco-Oakland-San Jose 

6,042 

37 

-122 

4.00 

-3 

Sacramento 

1,385 

38 

-121 

3.30 

-3 

Los Angeles-Anaheim-Riverside 

13,770 

34 

-118 

4.50 

-3 

San Diego 

2,370 

32 

-117 

3.30 

-3 

Phoenix 

2,030 

33 

-112 

3.30 

-2 

Salt Lake City-Ogden 

1,065 

40 

-111 

3.10 

-2 

Denver-Boulder 

1,858 

39 

-103 

3.10 

-2 

Houston-Galveston 

3,641 

32 

-100 

3.40 

-1 

San Antonio 

1,323 

30 

-98 

3.10 

-1 

Oklahoma City 

964 

35 

-97 

3.20 

-1 

Dallas-Fort Worth 

3,766 

32 

-97 

3.40 

-1 

Kansas City 

1,575 

39 

-94 

3.10 

-1 

Minneapolis-St. Paul 

2,388 

44 

-93 

3.30 

-1 

St. Louis 

2,467 

38 

-90 

3.20 

-1 

Memphis 

979 

35 

-90 

3.10 

-1 

New Orleans 

1,307 

29 

-90 

3.10 

-1 

Miiwaukee-Racine 

1,572 

42 

-87 

3.10 

-1 

Chicago-Gary Lake County 

8,181 

41 

-87 

3.90 

0 

Indianapolis 

1,237 

39 

-86 

3.10 

0 

Nashville 

972 

36 

-86 

3.10 

-1 

Birmingham 

923 

33 

-86 

3.10 

-1 

Louisville 

967 

38 

-85 

3.10 

0 

Cincinnati-Hamilton 

1,728 

39 

-84 

3.20 

0 

Dayton-Sprigfield 

948 

39 

-84 

3.20 

0 

Atlanta 

2,737 

33 

-84 

3.20 

0 

Detroit-Ann Arbor 

4,620 

42 

-83 

3.30 

0 

Columbus 

1,344 

39 

-83 

3.10 

0 

Tampa-St. Petersburg-Clearwater 

1,995 

27 

-82 

3.20 

0 

Cleveland-Akron-Lorain 

2,769 

41 

-81 

3.30 

0 

Jacksonville 

898 

30 

-81 

3.10 

0 

Orlando 

971 

28 

-81 

3.20 

0 

Pittsburgh-Beaver Valley 

2,284 

40 

-80 

3.20 

0 

Charlotte-Gastonia-Rocky Hill 

1,112 

35 

-80 

3.10 

0 

Miami-Fort-Lauderdale 

3,001 

25 

-80 

3.30 

0 

Greensboro- Winston-Salem-High 

925 

36 

-79 

3.10 

0 

Buffalo-Niagara Falls 

1,176 

42 

-78 

3.20 

0 

Rochester 

980 

43 

-77 

3.20 

0 

Washington 

3,734 

38 

-77 

3.30 

0 

Richmond-Petersburg 

844 

37 

-77 

3.20 

0 

Baltimore 

2,342 

39 

-76 

3.20 

0 

Philadelphia-Winington-Trenton 

5,963 

39 

-75 

3.80 

0 

Norfolk-Virginia Beach-Newport News 

1,380 

36 

-74 

3.20 

0 

Hartford-New Britain-Middleton 

1,068 

42 

-73 

3.00 

0 

Albany-Schenectady-T roy 

851 

42 

-73 

3.20 

0 

New York-New Jersey-Long Island 

18,120 

40 

-73 

5.00 

0 

Boston-Lawrence-Salem 

4,110 

42 

-71 

3.30 

0 

Providence-Pawtucket-Fall River 

1,125 

41 

-71 

3.00 

0 

San Juan-Caguas-Ponce, PR 

52 Count 

550 

18 

-66 

3.20 

5.00 Max 
329 Avg 

3.00 Min 

1 
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Table 3.2 ISDN User vs Industry 

SCAR Database 2. 



ISDN 

Industry 

% 

BROADCAST 

4.0 

COMMUNICATION 

10.0 

CONSTRUCTION 

2.0 

DATA PROCESSING 

2.0 

EDUCATION 

6.0 

ENERGY 

2.0 

FINANCIAL 

8.0 

FOOD SERVVICE 

2.0 

GOVERNMENT 

8.0 

LEGAL 

6.0 

LODGING 

4.0 

MANUFACTURING 

6.0 

MEDICAL 

6.0 

MILITARY 

10.0 

PUBLISHING 

4.0 

RECREATION 

4.0 

RESIDENTIAL 

2.0 

RETAIL 

4.0 

TRANSPORT 

6.0 

UTILITY 

2.0 

WHOLESALE 

2.0 

— 

— Check 

21 Count 

100.0 Normalization 
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3.2.4 Application versus Time Database (SCAR DB4). This database, 
Table 3.4, "Applications vs Time Database", associates daily time-slots for issuing ISDN 
distributions that are appropriate to the application being used in a scenario. 

3.2.5 Application vs Bearer Services Database (SCAR DB5). This 
database, Table 3.5, "Applications vs ISDN Bearer Service, Message Length Database", 
associates ISDN bearer services with the selected scenario application. For this SCAR 
program the following ISDN bearer services have been selected: circuit switched (64 kbps 
and 128 kbps), D-Channel X.25, B-Channel Frame Relay, and Telemetry. This database 
also associates the message length and message hold-time with each application. 

3.3 Scenario Generation Process: The scenario generation process uses 
the data from the traffic model database, described in Section 3.2 and generates a scenario 
traffic file (STF) of initial discrete events for the discrete event simulations described in 
Section 2.2.3. The STF consists of a time-ordered list of requests for a service and a 
release of that service when completed. For example. The STF discrete event requesting a 
circuit-switched B-Channel from Baltimore to Chicago at 0800 am looks like: 

Time CallRef# Action Resources Orig City Dest City 

0800 1012 Rqst CS64 Balt Chi 

The corresponding discrete event terminating this call, 31 minutes after its initiation, looks 
like: 

Time CallRef# Action 

0831 1012 Term 

In the STF discrete event terminating service the unique CallRef# is sufficient to identify 
that service being terminated. 

3.4 Scenario Generation Algorithm. The scenario generation program 
takes the data from the traffic model database and generates the corresponding STF entries. 
For example, to generate ISDN calls from Baltimore to Chicago the scenario script must 
have selected these two cities and possibly other cities. The following algorithm generates 
the associated ISDN service requests: 
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Table 3.4 

Application vs Time Database 





SCAR Database 4 




0001-0800 

0801-1200 

1201-1800 1801-2400 



mid/8am 

8am!noon 

noon/6pm 

6pmJmid 



8 hours 

4 hours 

6 hours 

6 hours 

Cheek 

APPLICATION 

TIMENOI 

TIMENOI 

TIMEN03 

TIMEN04 

Normaization 


% 

% 

% 

% 

% 

Voice(interactive) 

2.5 

32.0 

51.0 

14.5 

100.0 

Voice(message) 

2.5 

32.0 

51.0 

14.5 

100.0 

Facsimile 

2.5 

32.0 

51.0 

14.5 

100.0 

FileTransfer 

52.0 

3.0 

5.0 

40.0 

100.0 

VideoBroadcasting 

10.0 

25.0 

30.0 

35.0 

100.0 

VideoConference 

2.5 

32.0 

51.0 

14.5 

100.0 

InteractiveData 

2.5 

32.0 

51.0 

14.5 

100.0 

Transaction 

2.5 

32.0 

51.0 

14.5 

100.0 

Teletex 

2.5 

32.0 

51.0 

14.5 

100.0 

Communications Check Sum: 

79.5 

252.0 

392.0 

176.5 

900.0 






900.0 
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1 . From SCAR DB 1 the population of Baltimore is cited as 2,342,000 with 
3.2% of them being daily ISDN users. Therefore, the number of daily 
ISDN service calls from Baltimore is 74,944. 

2. If the scenario script selected, only the following Baltimore industries 
having the corresponding ISDN percentages in SCAR DB2 then the total 
daily ISDN service calls from Baltimore by industries would amount to: 



ISDN% 

ISDN Calls 

Broadcast 

4.0% 

2,998 

Communication 

10.0% 

7,494 

Education 

6.0% 

4,497 


3 . If the scenario script further restricted the applications to Voice(Interactive), 
Voice(Message), and Facsimile, then these Baltimore ISDN service calls are 
further partitioned by this matrix from SCAR DB3: 



Voice(I) 

Voice(M) 

Facsimile 

Broadcast 

3.0% 

0.5% 

1.0% 

Communication 

6.0% 

5.0% 

10.0% 

Education 

5.0% 

5.0% 

5.0% 


The resulting ISDN service calls from Baltimore in those areas are: 



Voice(I) 

Voice(M) 

Facsimile 

Broadcast 

90 

15 

30 

Communication 

450 

375 

750 

Education 

225 

225 

225 


4. If the scenario script again further restricts the applications to following 
bearer services: CS64KBPS, CS128KBPS, and DX25 as cited in SCAR 
DB5, then the following Baltimore ISDN service calls are associated with 
the ISDN bearer services: 
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CS64KBPS 

CS128KBPS 

DX25 

Voice(Interactive) 

100% 

0% 

0% 

Broadcast 

90 

0 

0 

Communication 

450 

0 

0 

Education 

225 

0 

0 


CS64KBPS 

CS128KBPS 

DX25 

V oice(Message) 

100% 

0% 

0% 

Broadcast 

15 

0 

0 

Communication 

375 

0 

0 

Education 

225 

0 

0 


CS64KBPS 

CS128KBPS 

DX25 

Facsimile 

80% 

15% 

2% 

Broadcast 

24 

5 

1 

Communication 

600 

113 

15 

Education 

180 

34 

5 


5. These three applications have the same call distribution over time, see 
SCARDB4: 


Time 

0001- 

0801- 

1201- 

1801- 

(hours) 

0800 

1200 

1800 

2400 


Time 1 

Time 2 

Time 3 

Time 4 

Voice(Interactive) 

2.5% 

32.0% 

51.0% 

14.5% 

Voice(Message) 

2.5% 

32.0% 

51.0% 

14.5% 

Facsimile 

2.5% 

32.0% 

51.0% 

14.5% 
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The number of call in each time slots T1/T2/T3/T4 for each Baltimore ISDN service call 
category is: 



CS64KBPS 

CS128KBPS 

DX25 

Voice( I nter active ) 

100% 

0% 

0% 

Broadcast 

45 

0 

0 


2/28/46/14 

o/o/o/o 

o/o/o/o 

Communication 

450 

0 

0 


11/144/220/65 

o/o/o/o 

o/o/o/o 

Education 

225 

0 

0 


6/72/114/33 

o/o/o/o 

o/o/o/o 



CS64KBPS 

CS128KBPS 

DX25 

Voice(Message) 

100% 

0% 

0% 

Broadcast 

15 

0 

0 


0/5/8/2 

o/o/o/o 

o/o/o/o 

Communication 

375 

0 

0 


9/120/191/55 

o/o/o/o 

o/o/o/o 

Education 

225 

0 

0 


6/72/114/33 

o/o/o/o 

o/o/o/o 



CS64KBPS 

CS128KBPS 

DX25 

Facsimile 

80% 

15% 

2% 

Broadcast 

24 

5 

1 


1/8/12/3 

0/2/3/0 

0/0/1/0 

Communication 

600 

112 

15 


15/192/306/87 

3/36/58/16 

0/5/8/2 

Education 

180 

34 

5 


4/58/92/26 

1/11/17/5 

0/2/3/0 
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Within each of these time-slots the ISDN service calls are assumed to be uniformly 
distributed In our example, the 45 ISDN calls from Baltimore that are associated with the 
broadcast industry that use the CS64KBPS ISDN bearer service fall into a 1/14/23/7 time- 
slot distribution pattern. This means that : 

1 ISDN call will be selected from a uniform distribution between 0001-0800 hrs, 

14 ISDN calls will be selected from a uniform distribution between 0801-1200 hrs, 

23 ISDN calls will be elected from a uniform distribution between 1201-1800 hrs, and 
7 ISDN calls will be selected from a uniform distribution between 1801-2400 hrs. 


A sequence number is produced by the ScenGen program to uniquely identify each call. 
The resulting STF for initiating these 45 ISDN service calls from Baltimore could look: 


Time 

CallRef 

Action Rersour 

OrigCity DestCity 

0700 

0001 

Rqst 

CS64 

Balt 

* 

* — 

where: 

represents a city selected from a uniform distribu- 
tion of those cities selected by the scenario script. 

0815 

0002 

Rqst 

CS64 

Balt 

* 


0830 

0003 

Rqst 

CS64 

Balt 

* 


1148 

0015 

Rqst 

CS64 

Balt 

* 


1215 

0016 

Rqst 

CS64 

Balt 

* 


1232 

0017 

Rqst 

CS64 

Balt 

* 


1749 

0038 

Rqst 

CS64 

Balt 

* 


1816 

0039 

Rqst 

CS64 

Balt 

* 


1915 

0040 

Rqst 

CS64 

Balt 

* 


2347 

0045 

Rqst 

CS64 

Balt 

* 



6. The length of time associated with the use of these ISDN bearer services is 
proportional to the hold-time for that service. SCAR DB5 cites these hold- 
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times as a function of the application. For our example of the 45 
CS64KBPS messages the hold-time is 3 minutes. Using a uniform 
distribution with a parametric value of 3, hold-times are determined for each 
ISDN call. That hold-time is added to the call request event time to 
determine the call termination event time. The resulting STF is shown 
below. The unique CallRef# is sufficient to handle the disconnect request 


Time 

CallRef 

Action Rersour 

OrigCity DestCity 

0700 

0001 

Rqst 

CS64 

Balt 

* 

where: 

0702 

0001 

Term 



* = 

represents a city selected from a uniform distribu- 







tion of those cities selected by the scenario script. 

0815 

0002 

Rqst 

CS64 

Balt 

* 


0818 

0002 

Term 





0830 

0003 

Rqst 

CS64 

Balt 

* 


0831 

0003 

Term 





1148 

0015 

Rqst 

CS64 

Balt 

* 


1201 

0015 

Term 





1215 

0016 

Rqst 

CS64 

Balt 

* 


1218 

0016 

Term 





1232 

0017 

Rqst 

CS64 

Balt 

* 


1233 

0017 

Term 





1749 

0038 

Rqst 

CS64 

Balt 

* 


1750 

0038 

Term 





1816 

0039 

Rqst 

CS64 

Balt 

* 


1818 

0039 

Term 





1915 

0040 

Rqst 

CS64 

Balt 

* 


1918 

0040 

Term 





2347 

0045 

Rqst 

CS64 

Balt 

* 


2349 

0045 

Term 






3-15 



This STF suitably represents the ISDN user traffic for the SCAR network model and 
simulation. There are sufficient degrees of freedom to permit a number of tailored 
scenarios to determine the ISDN communications satellite design parameter limits, test 
subsystems and procedure and stress the overall system. An example of scenario profile 
for four cities: Baltimore, Chicago, Los Angeles, and San Francisco using the industries of 
broadcast, construction, communications, data processing, and education across all bearer 
services is shown in Figure 3.4, "Scenario Generation Example". 

3.5 Scenario Scripts. Scenario scripts consists of descriptive text that 

presents the objectives, goals, strategy, and the selected scenario components that are to be 
used to generate a given scenario. These scenario scripts are used in conjunction with the 
ScenGen program and the traffic model database. Each scenario has a reason for being. 
They address a specific aspect of the NASA SCAR design for an advanced ISDN 
communications satellite. The ISDN satellite topology, design parameters, and 
environment are part of the simulation initial conditions for the subsequent scenario 
discrete events requesting and relinquishing ISDN bearer services. 

3.5.1 Scenario Scripts Types. Four types of scenarios will be used in this 

NASA SCAR Program: checkout, baseline, stress, and special scenarios. A checkout 
scenario will be used to verify the functionality of various sets of ISDN subsystems of the 
satellite design. The objectives here are to quickly and easily demonstrate that the actions 
and protocols that accompany a specific ISDN bearer service are modeled and simulated 
properly and are operating as described in the standards. Five checkout scenarios are 
planned for this NASA SCAR Program: CS64, CS128, DX25, BFRAMERELY, and 
TELEMETRY. These checkout scenario address the bearer services that are identified in 
the traffic model database. 

A baseline scenario will be developed and used as standard for all NASA SCAR Program 
simulations. The purpose is to provide a benchmark that will produce comparable results 
as the advanced ISDN communications satellite design evolves. This baseline scenario 
should include a sufficient variety of ISDN traffic to adequately gauge the satellite design. 

Stress scenarios will be developed to determine the limits of the ISDN communications 
satellite design. The objective is to find the break points in the design in order to determine 
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Figure 3.4 Scenario Generation Example 





the engineering and operating envelop for the system. Three stress scenarios are planned: 
traffic stress, environment stress, and link breakdown stress. The traffic stress scenario 
will the message scale factor to systematically increase the traffic of an ISDN message 
distribution until a failure occurs. The environment stress scenario will systematically add 
weather losses to the system to determine the utility of weather mitigating techniques. The 
link-breakdown stress scenario will systematically disable single communication links to 
simulate a link-breakdown in order to determine the system robustness. 

Special scenario will be developed on a demand basis to investigate specific attributes of the 
ISDN communications satellite design. At least one special scenario will be developed for 
this NASA SCAR Program. 

3.5.2 Scenario Scripts Options. The rationale for a scenario script must 
include a list of traffic model database components that are to participate in the scenario. 
Figure 3.5, "Scenario Selection Options", shows the database architecture for the traffic 
model indicating the scenario selection options that are available. Once these options are 
selected, the ScenGen program automatically implements the algorithm presented in Section 
3.4 to generate a STF for the ISDN network model simulation. By selecting combinations 
of cities, industries, applications, time-slots, and bearer services 204,120 ISDN message 
elements can be formed into any distribution of ISDN message traffic. A message scale 
factor is used to sculpture this ISDN message distribution to suit the traffic load desired. 

The scenario selection process, as part of ScenGen, consists of: 

• Selecting the cities 

• Selecting the industries 

• Selecting the applications 

• Selecting the time-slots 

• Selecting the bearer services 

• Choosing a message factor. 

Table 3.6, "Scenario Generation (ScenGen) Selection Process" summarizes the scenario 
structure for the scenario types that will be described below. Each column represents a 
specific scenario type identifying the selected cities, industries, applications, time-slots 
bearer services, and message scale factor. 

3.5.3 Checkout Scenario Script. The five checkout scenarios consist of an 
exchange of ISDN traffic between an east coast city and a west coast city. Since these 
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scenarios are used to check out the operations of a particular ISDN bearer services, only 
that bearer service is selected. According to the traffic model database the communications 
industry is the greatest user of ISDN services, therefore, it was selected for all the checkout 
scenarios. A different application was selected for each checkout scenario to provide some 
degree of variety. All possible time-slots were selected and a unity message scale factor 
was used. The number of ISDN service requests and terminations varied from thousands 
to tens of initiating discrete event messages in line with the scenario selection process. 
Since all these scenarios are to be used primarily for ISDN subsystem functional 
verifications the message count is not as important as the protocol sequence that tasks the 
ISDN services. 

3.5.4 Baseline Scenario Script. Again, as shown in Table 3.6, the baseline 
scenario used all the cities from all the checkout scenario generating 2.4 million potential 
ISDN service requests. This traffic is the sculptured by selecting the top eight ISDN user 
industries: communications, education, financial, government, manufacturing, medical, 
military, and transportation resulting in 1.4 million ISDN service requests. These ISDN 
service requests are distributed over all application, time-slots, and ISDN bearer services. 
A unity message scale factor is used. 

This baseline scenario will be used a benchmark to evaluate the progress of the evolution 
and variations of the advanced ISDN communications satellite design. 

3.5.5 Stress Scenario Script. The traffic stress scenario consists of the 
baseline scenario with a message scale factor of five. As shown in Table 3.6, over 7.2 
million request for ISDN data services are presented to the ISDN network model 
simulation. If no break-down point is achieved with this stress scenario, the message scale 
factor will be increase until the weakest link in the ISDN network is exposed. 

The link-loss scenario consists of using the baseline scenario and introducing specific 
communication link breakdowns as a function of time during the execution of the STF. 
This will permit a comparable evaluation between benign environment of the baseline 
scenario and the link-loss scenario. 

Similarly the weather environment scenario will use the baseline scenario that includes 
variations of propagation parameters related to weather. The weather mitigating subsystem 
models should be automatically compensate for some level of weather interference 


3-21 



3.5.6 Special Scenario Script. The special scenario will be devised on a 

demand basis. A set of cities, industries, applications, time-slots, bearer services and 
message scale factor will be used to provide a special ISDN distribution of traffic. 

For example, a Mother’s Day scenario could have all cities using interactive voice on CS64 
bearer service all day with a message scale factor corresponding the the known traffic 
volume. 

Another example, a Sports Relay could have two cities using B-FRAMERELAY bearer 
service for a four hour period to provide that sport event coverage to other part of the 
country. 


SECTION 4 

PERFORMANCE MEASURES 


4.1 Introduction. As shown in Figure 4.1, "Performance Measures - 
Introduction", the performance measure definitions effects all aspects of this SCAR 
program. Performance measures will be used to evaluate both the hardware and software 
for the advanced ISDN communications satellite design. As such these performance 
measure must be associated with observables that can quantified and impartially measured. 
In general these performance measures must be in line with CCITT standards especially as 
they pertain to satellite service in ISDN. 

These performance measures must be integrated into both the scenario generations process 
to focus attention on what is to be measured and on the modeling and simulation software 
to ensure that the parameters necessary for these measures are included in the design. 
Using the user perspective, these performance standards are derived for communication 
links in end-to-end connections. 

After a brief introduction, definitions and the purpose of performance measure will be 
addressed. Categories of performance measures will be identified and described. A 
summary of the performance measures methodology will be provided. 

4.2 Definition and Purpose. Performance measures must identify with 
those elements of the system that are critical to the system performance. They must also 
provide a quantitative unit of measure for these element performance. The development of 
these performance measures forces a systematic approach to the technical definitions of the 
system modeling/simulation objectives. They provide the basis for the design for the 
system simulations and lead to the documentation of the technical objectives of the system 
model and simulation. 

4.3 Performance Measures Categories. We have identified four 
categories of performance measures for the SCAR advanced ISDN communications 
satellite system: throughput, response time, blocking probability, and robustness. Each is 
discussed in turn. 
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4.3.1 Throughput. Throughput refers to the communications capacity to 
transfer a quantifiable amount of communications traffic, see Figure 4.2, "Performance 
Measure - Throughput". It can be quantified in several unit of measure: bits per seconds, 
messages per seconds, frame pers seconds, number of simultaneous channels, etc. 

A number of ISDN communications satellite design factors contribute to the 
communications throughput. The intrinsic ISDN channel capacity of the B-Channel and D- 
Channel and their bundling into a T1 structure form a natural restriction on throughput. 
The satellite connectivity further constrains this potential ISDN throughput. Satellite 
antenna gains, beam widths, and dwell capabilities mitigate the communications capacity. 
The uplink/downlink accesses using TDMA slots, FDMA frequencies, and CDMA codes 
restrict the number of ISDN channels that can be serviced. In term of protocol and traffic 
queuing the buffer sizes and the processor speeds meaningfully affect the throughput. 

Throughput evaluations apply at all level of communications and therefore affect all major 
modeling and simulation modules. Since in a satellite environment the traffic shares many 
of the communication links with the control protocol, both traffic and protocol throughput 
must be considered in the analysis of throughput. 

The throughput performance measure will be the number of B-Channels that be 
simultaneously supported or the bits per second of uplink and downlink capacity. 

4.3.2 Response Time. Response time refers to the speed at which a system 
can supply throughput, see Figure 4.3, "Performance Measure - Response Time". It can 
be quantified in the time required to set up a circuit, the time from the sending to the receipt 
of a packet, the time from keyboard selection to screen response, etc. 

Response time in a satellite communications system is principally limited by the 
propagation delays between the ground stations and the satellite. Processing time delays 
contribute in proportion to software that must be executed to support communications. In 
an ISDN software intensive system this means that much attention must be given to 
software execution times. The satellite antenna reaction and revisit times add linearly to the 
response time. The time it takes for an uplink access is limited by framing time and 
contention resolution time of the modulation scheme and the contention algorithm. 
Response time is also extended by the time-outs within the ISDN and SS7 protocols, and 
by the coding delays that accompany error detection and error corrections. 
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Figure 4.2 Performance Measure - Throughput 
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Though the response time is principally involved with the set up time of an ISDN 
communications channel it permeates every communication subsystem and every model 
and simulations module. Every stage of protocol processing and traffic moving takes time 
that can be accumulated into response time. The response times at all first level interfaces 
are most visible but the response times associated with decision logic depth for ISDN and 
SS7 protocol processing in the on-board processor (OBP) could be of comparable 
magnitude. 

The measure of response time will be the time it takes set up an ISDN service from the time 
it was requested. 

4.3.3 Blocking Probability. Blocking probability refers to the likelihood that 

a given call request can not be satisfied, see Figure 4.4, "Performance Measure - Blocking 
Probability". It is quantified by a probability number between zero and unity. The 
objective is to seek the lowest blocking probability for a given design. 

The factors that contribute to the communications blocking probability generally deal with 
limits on available resources: channels, buffers, or time. Though the capacity of the D- 
Channel for control could limit the assignment of the bearer service B-Channels, the ISDN 
architecture has generally provide sufficient control channel margin. In an ISDN 
communications satellite architecture, however, the number of B-channel resources that can 
be allocated is more limited than in the terrestrial environment. The denial of uplink access 
is not generally considered part of the blocking probability. It acts like the line-finder 
access to telephone exchanges and is more associate with availability. But in advanced 
ISDN communications satellites where the OBPs control the assignment of the bearer 
services, B-Channels, and the downlink transmission paths, call blocking can occur when 
any of these resources are unavailable. 

From an application point of view the blocking probability is associated with the ability of 
the OBP to assign the resources to complete an ISDN service. At that decision point the 
OBP logs the request for ISDN service as being blocked, and takes the appropriate steps to 
inform the requesting party. A more general view of blocking probability would include 
denial of uplink access and unavailability of intermediate buffers, but there are no 
mechanisms in the real world for accumulating these statistics or informing the party being 
blocked. 
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The measure of blocking probability will be the number or percentage of ISDN service 
requests that are denied by the OPB due to the lack of resources. 

4.3.4 Robustness. Robustness refers to ability of the system to recover from 
any finite state transitions, see Figure 4.5, "Performance Measure - Robustness". 

A number of factors can be associated with robustness. Robustness must counter many 
forms of inadvertent events and states. Each of these undesirable events and states must 
rectified but unique singular solutions. To recover from an undesired logic state the 
solution relies on prevention software to avoid that logic state or special time-out or 
correction software to exit the undesired logic state. Buffer or stack overflows must 
correctable on the spot, in real-time, and with minimal information loss. Locked up 
capacity on the B-Channels and D-Channels must be resolved by early detection and the 
selective shedding of load. The protocol must capable of positive recovery from any loss 
of response usually after some time-out period. Erroneous routing must resolved by 
default options or centralized review by the OBP for action. 

Though most effects of robustness can be resolved by the OBP many unpredictable actions 
or operations will require reviewing and redressing to recover from undesirable events or 
states. 

f 

The measure of robustness will be the number ISDN communications anomalies that occur 
after the network model and simulation has been checked out and debugged for the 
advanced ISDN communications satellite. 

4.4 Performance Measures Summary. The selection of these 
performance measures is essential for the success of this research. Their integration into 
the design, model, and simulation of an advanced ISDN communications satellite is shown 
in Table 4.1, "NASA SCAR Performance Measures Matrix". 

As such these performance measures determine the complexity of the design, model, 
simulation and analysis associated with the NASA SCAR Program. Therefore, these 
performance measures must be prioritized as to the relative importance to allow some 
flexibility in controlling scope of the NASA SCAR effort. 
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SECTION 5 
SUMMARY 


5.1 General. This update report presented the views of the scenario 
generation process and the performance measurement methodology. The process and 
methodology are applicable to the the Interim Service ISDN Satellite (ISIS) and the Full 
Service ISDN Satellite (FSIS). The ultimate aim of this aspect of the SCAR Program is the 
design of a new advanced ISDN communications satellite. The technical and operational 
parameters for this ISDN advanced communications satellite design will be obtained from 
an engineering software model of the major subsystems of the ISDN communications 
satellite architecture. Discrete event simulation experiments will be performed with the 
model using various traffic scenarios, technical parameters, and operational procedures. 
These data from those simulations will be analyzed using the performance measures 
discussed in this report. 

5 . 2 Review. After an introduction that provided the background and scope of 
this NASA SCAR Program, the use of modeling and simulation to determine the 
parameters for the advanced ISDN communications satellite design was presented. An 
overview of the modeling and simulation tasks included a brief description of the four 
software programs for the effort. Particular associations were made between the the 
Scenario Generation Program and the Scenarios described herein, and the Product 
Generation Program and the Performance Measures just discussed. The two main sections 
of this update report are Scenario Generation and Performance Measures. 

The Scenario Generation Section described the Scenario Generation Program and its 
association with the Traffic Model Database. After a brief description of the traffic model 
database elements, they were used in a scenario generation example demonstrating their 
flexibility and utility in generating a STF. Four types Scenario Scripts were defined: 
checkout, baseline, stress, and special scenarios. Each were described in detail together 
with their utility to the SCAR advanced ISDN communications satellite design process 

The Performance Measures Section introduced the concepts, definitions, and purposes of 
these measures. Four performance measure categories were identified: throughput, 
response time, blocking probability, and robustness. Each was presented in detail 
identifying their major factors, their application levels, and their measures for the NASA 
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SCAR effort. A summary matrix was generated associating the performance measures 
with the major subsystems of the modeling and simulation effort 

5 . 3 Results. The research and results in both the scenario generation and the 

performance measures areas are adequate to support the other tasks of this NASA SCAR 
Program. Only minor refinement will be needed to integrate these scenarios and 
performance measures with the traffic model and network model simulation of the NASA 
SCAR advanced ISDN communications satellite. 
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